home *** CD-ROM | disk | FTP | other *** search
/ C/C++ Users Group Library 1996 July / C-C++ Users Group Library July 1996.iso / vol_300 / 301_01 / dcuwcu.doc < prev    next >
Text File  |  1989-12-28  |  14KB  |  348 lines
  1.  
  2.  
  3.  
  4.               DCUWCU - A Simple Application Environment 
  5.  
  6.                            Mark A. Johnson
  7.  
  8.  
  9.  
  10.  
  11.      1.  Introduction
  12.  
  13.      I have used a mouse in computer user interfaces since 1981 
  14.      and feel it is the best and most convenient way to inform a 
  15.      computer program what you would like it to do.  I wanted to 
  16.      use a mouse in a number of programs for the PC and looked 
  17.      into a few application environments, such as Microsoft 
  18.      Windows and Digital Research GEM, but was disappointed to 
  19.      see how much complexity had to be mastered.  Most of the 
  20.      programs I had in mind needed only a mouse controlled 
  21.      cursor, a simple menu structure, and editable forms.  The 
  22.      resource construction sets, complex window management, and 
  23.      other overheads needed to write a simple application led me 
  24.      to write my own simple application environment based on 
  25.      Turbo C graphics routines and a public domain mouse 
  26.      interface.  My goal was to build a easy-to-use environment 
  27.      that provides a mouse-driven cursor, stacked pop-up menus, 
  28.      and forms that contain editable fields and a variety of 
  29.      selectable buttons.  The environment would keep track of 
  30.      what the user was doing, inform the application as needed, 
  31.      and clean up after itself.  An additional goal was to make 
  32.      it easy to port the environment to other machines that have 
  33.      a mouse, bitmap graphics, console I/O, and a simple timer.  
  34.      I have the same DCUWCU environment on my PC compatible and 
  35.      Atari ST, allowing me to easily move applications between 
  36.      systems.  
  37.  
  38.      2.  Operation
  39.  
  40.      A typical application begins with a blank screen, or 
  41.      suitable greeting, showing an arrow shaped cursor controlled
  42.      by the mouse.  Pressing the right mouse button displays a 
  43.      set of stacked pop-up menus.  While holding the right mouse 
  44.      button down, the user selects an item from the front-most 
  45.      menu or selects another menu and releases the right mouse 
  46.      button.  If a menu item was selected, then the application 
  47.      acts on the selection.  If another menu was selected, it is 
  48.      brought to the front of the menu stack ready for another 
  49.      round of menu item selection.  Pressing the left mouse 
  50.      button or the keyboard usually causes an application 
  51.      specific action.  Often such actions result in a form 
  52.      appearing on the screen to be filled out by the user.  When 
  53.      processing a form, all mouse and keyboard events are handled
  54.      by the environment.  Keyboard input is directed to the 
  55.      current editable field, denoted by the special input cursor.
  56.      A TAB moves the input cursor to the next editable field.  An
  57.      ESC (cancel) or ENTER (accept) ends form processing, 
  58.      returning data and control back to the application.  Some 
  59.  
  60.  
  61.  
  62.  
  63.  
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70.                                 - 2 -
  71.  
  72.  
  73.  
  74.      forms may contain small text labels, called form buttons, 
  75.      that are selected (or de-selected) by moving the cursor over
  76.      them and pressing the left mouse button.  There are three 
  77.      types of buttons: plain, radio, and exit.  A plain button is
  78.      a simple on/off switch.  A radio button is a one-of-many 
  79.      switch, much like the buttons on a car radio.  An exit 
  80.      button is like the plain button, but selecting it will cause
  81.      form processing to end.  
  82.  
  83.      The application environment also works equally well when no 
  84.      mouse is present by using the cursor keys to simulate mouse 
  85.      motion and the function keys F1 and F2 to simulate the left 
  86.      and right mouse buttons.  It takes one press of F2 to 
  87.      simulate depressing the right mouse button and another press
  88.      of F2 to release it.  A single press of the F1 button 
  89.      simulates the left mouse button.  
  90.  
  91.      3.  Application Interface
  92.  
  93.      An effort was made to keep the interface between application
  94.      and environment as simple as possible: strings are used to 
  95.      define forms and menus, pointers to variables are used to 
  96.      store values collected by forms, and calls to functions 
  97.      inform the application of user events such as menu selection
  98.      or mouse button clicks.  
  99.  
  100.      The application environment follows (and is named after) 
  101.      what is called "The Hollywood Principle," or "don't call us,
  102.      we'll call you." An application developer supplies four 
  103.      critical routines that are called when the application 
  104.      environment detects various user interface events.  
  105.  
  106.           start(argc, argv, envp) int argc; char **argv, **envp;
  107.      This is the initialization routine called immediately after 
  108.      the graphics interface is initialized but before the 
  109.      environment is completely started.  It is passed the same 
  110.      arguments that are normally passed to a C main() routine.  
  111.      The start() routine usually initializes the application and 
  112.      creates the menu stack using repeated calls to add_menu().  
  113.  
  114.           menu(m, i)
  115.      The menu() routine is called whenever a menu selection is 
  116.      made.  The application environment supports a stack of 
  117.      pop-up menus.  Any number of menus can be supported, 
  118.      although usually only two or three are active at any one 
  119.      time to minimize interface complexity (see menu_state() 
  120.      below).  The m argument identifies which menu was selected.
  121.      When the menu was first declareed (see add_menu()), the 
  122.      application provides a value that identifies the menu.  This
  123.      same identifer value is passed back to the application when 
  124.      a menu is selected.  The i argument specifies which menu 
  125.  
  126.  
  127.  
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136.                                 - 3 -
  137.  
  138.  
  139.  
  140.      item was selected with a value of 1 meaning the first item, 
  141.      etc.  
  142.  
  143.           button(b, x, y)
  144.      The button() routine is called when a user mouse button is 
  145.      pressed.  The right mouse button is reserved for menu 
  146.      manipulation, all others are passed to the application.  The
  147.      b argument is the button number (usually 1) and the x and y 
  148.      arguments are the mouse coordinates when the button was 
  149.      pressed.  
  150.  
  151.           keyboard(key)
  152.      The keyboard() routine is called whenever a console key is 
  153.      struck.  The character typed by the user is contained in the
  154.      single argument.  
  155.  
  156.           timer(t)
  157.      The (optional) timer() routine is called whenever a 
  158.      application requested timer expires.  When the timer is 
  159.      requested, a value identifying the timer is passed to the 
  160.      application environment.  The same identifer value is passed
  161.      back to the application in the t argument when the timer 
  162.      expires.  
  163.  
  164.      4.  Environment Interface
  165.  
  166.      There are some basic routines provided by the application 
  167.      environment that an application can call for control and 
  168.      service.  
  169.  
  170.           finish()
  171.      The finish() routine is called whenever the application is 
  172.      done and the program must exit.  
  173.  
  174.           add_menu(m, mdef) char *mdef;
  175.      The add_menu() routine adds a menu to the current set of 
  176.      pop-up menus maintained by the environment.  An application 
  177.      typically initializes all its menus from the start() 
  178.      routine.  The m argument is remembered by the environment 
  179.      and passed back to the application when a menu selection is 
  180.      made.  The mdef argument is a string that defines the menu.
  181.      For example, add_menu(1, "Main:About|Help|Quit") defines a 
  182.      menu identified as menu 1, titled Main, and with three 
  183.      items: About, Help, and Quit.  
  184.  
  185.           menu_state(m, on)
  186.      The menu_state() routine allows the application to activate 
  187.      or de-activate a particular menu.  The m argument refers to 
  188.      the menu defined with a previous add_menu() call.  The on 
  189.      argument should be set to 1 to activate or 0 to deactivate 
  190.      the menu.  
  191.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.                                 - 4 -
  203.  
  204.  
  205.  
  206.  
  207.           menu_item(m, i, str) char *str;
  208.      The menu_item() routine is used to change the name of a 
  209.      par